Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

/azp list

/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-extra-platforms, runtime-coreclr pgostress

/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-extra-platforms, runtime-coreclr pgostress

@MihuBot

/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-extra-platforms, runtime-coreclr pgostress

Seems like we ought to put the calls to getExactClasses into impIsClassExact to centralize the logic, and then just have these methods simply call impIsClassExact if they don't have exact classes.

As far as I know that's not needed because impIsClassExact already doing the right thing on NativeAOT by checking "is effectively sealed" (meaning no subclasses)

so the getExactClasses == 1 check in this pr should be completely redundant

Seems like we ought to put the calls to getExactClasses into impIsClassExact to centralize the logic, and then just have these methods simply call impIsClassExact if they don't have exact classes.

As far as I know that's not needed because impIsClassExact already doing the right thing on NativeAOT by checking "is effectively sealed" (meaning no subclasses)

so the getExactClasses == 1 check in this pr should be completely redundant

So (perhaps I'm finally understanding what you were saying above) the only change needed is to one call to impClassIsExact

@MichalPetryka can you please try just running with that one change?

@MihuBot -hetzner

The x86 failure here is a bit concerning. We are crashing in the GC.

Assert failure(PID 32236 [0x00007dec], Thread: 10744 [0x29f8]): Consistency check failed: AV in clr at this callstack:
------
CORECLR! WKS::gc_heap::background_mark_simple + 0x21 (0x702b6364)
CORECLR! WKS::gc_heap::background_promote + 0x109 (0x702b6a79)
CORECLR! PinObject + 0x91 (0x702807f1)
CORECLR! ScanConsecutiveHandlesWithoutUserData + 0x44 (0x7027fab4)
CORECLR! BlockScanBlocksWithoutUserData + 0x29 (0x7027f5e9)
CORECLR! ProcessScanQNode + 0x32 (0x7027f982)

The x86 failure here is a bit concerning. We are crashing in the GC.

I don't recall that being there before, could it maybe be the rebase on top of main that caused this?

    diff is a regression.
    relative diff is a regression.

262 improved, 1904 regressed

why is this acceptable?

The x86 failure here is a bit concerning. We are crashing in the GC.

Assert failure(PID 32236 [0x00007dec], Thread: 10744 [0x29f8]): Consistency check failed: AV in clr at this callstack:
------
CORECLR! WKS::gc_heap::background_mark_simple + 0x21 (0x702b6364)
CORECLR! WKS::gc_heap::background_promote + 0x109 (0x702b6a79)
CORECLR! PinObject + 0x91 (0x702807f1)
CORECLR! ScanConsecutiveHandlesWithoutUserData + 0x44 (0x7027fab4)
CORECLR! BlockScanBlocksWithoutUserData + 0x29 (0x7027f5e9)
CORECLR! ProcessScanQNode + 0x32 (0x7027f982)

@dotnet/gc any thoughts on this? I can load up the dump but can't get SOS to work.

    diff is a regression.
    relative diff is a regression.

262 improved, 1904 regressed

why is this acceptable?

We are expecting this change to unblock more devirtualization and inlining, so some size increases are expected.

    diff is a regression.
    relative diff is a regression.

262 improved, 1904 regressed

why is this acceptable?

We are expecting this change to unblock more devirtualization and inlining, so some size increases are expected.

Also we expect the size increases in practice will be smaller since many of those same inlines are already happening under PGO-driven GDV. But we can't see that impact easily right now.

Once this change is in and we do new SPMI collections we can undo it and get a more accurate read on the size impact.

the test failure appears to be a GC hole, so might be useful to try with HeapVerify enabled to check if repros consistently.

the test failure appears to be a GC hole, so might be useful to try with HeapVerify enabled to check if repros consistently.

Let me see if it repros in CI.

I can't seem to get rerun to actually rerun the failing test.

@MichalPetryka please push a merge commit once #88856 is in so we can start from scratch.

/azp run runtime-coreclr outerloop, runtime-extra-platforms, runtime-coreclr pgostress

Going to bounce this...

Actually let me merge this up.

@MichalPetryka thank you!